In the following some of the terminology used throughout this application is explained.
MIP (client Mobile IP): a host-based mobility mechanism. The client (host or mobile node, MN) sends registration messages to the home agent (HA) in order to register its new location. The Mobile IP version 6 (MIPv6) protocol is specified in Johnson et al., 2004 (D. Johnson, C. Perkins, J. Arkko, “Mobility Support in IPv6”, RFC 3775, June 2004).
PMIP (Proxy Mobile IP): a network-based mobility mechanism based on the Mobile IP protocol. A proxy mobility entity (called Mobile Access Gateway, MAG) sends registration messages on behalf of the MN to the HA in order to register the MN's new location. Since the HA in PMIP is modified to handle the proxy registrations by the MAG, it is called Local Mobility Anchor (LMA). In PMIP mechanism the MN is not involved in the mobility-related procedures. The Proxy MIPv6 protocol (PMIPv6) is an ongoing work and the current specification is described in Gundavelli et al., 2007 (S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, “Proxy Mobile IPv6”, RFC5213, August 2008). Please note that within this document the term PMIP has the meaning of network-based, e.g. “PMIP mobility” may be used interchangeably with “network-based mobility”.
Binding Update (BU): a registration message sent by a mobile node or respectively MAG to notify the HA or respectively LMA about the new address (i.e. topological location) of the MN. In this invention we differentiate between BUs send by the MN in host-based mobility mechanism, called BU hereinafter, and BUs send by the MAG in network-based mobility mechanism, called PBU (for proxy-BU) in the following. Analogously, a binding update acknowledgement message sent by the host is indicated as BA and binding update acknowledgement message sent by the MAG is indicated as PBA (for proxy-BA).
Keygen token: a keygen token is a number supplied by a CN in the return routability procedure to enable the mobile node to compute the necessary binding management key for authorizing a Binding Update sent to the CN.
Binding cache entry: A Home Agent on the home link maintains a binding cache entry for each mobile node and uses the binding cache entry to route any traffic meant for the mobile node or the mobile network. Usually the binding cache entry binds the home address of a mobile node to its care-of-address. If the mobile node does not have a binding cache entry at the Home Agent, it is neither reachable at its home address nor able to set up new sessions with its home address. A binding cache entry can also exist in a client (e.g. a correspondent node) that is established by another client (e.g. mobile node). The binding cache entry is also described as a routing state because it changes the entries in the routing table.
In the following the co-location of HA and LMA is denoted as HA/LMA.
Communications systems evolve more and more towards an Internet Protocol (IP)-based network. They consist of many interconnected networks, in which speech and data is transmitted from one terminal to another terminal in pieces, so-called packets. Those packets are routed to the destination by routers in a connection-less manner. IP packets consist of IP header and payload information, whereas the IP header comprises, among other things, source and destination IP address. For scalability reasons an IP network uses a hierarchical addressing scheme. Hence, an IP address does not only identify the corresponding terminal, but additionally contains location information about this terminal.
With additional information provided by routing protocols, routers in the network are able to identify the next router towards a specific destination.
If a terminal is mobile, from now on called Mobile Node (MN), and moves between subnets, it must change its IP address to a topologically correct IP address because of the hierarchical addressing scheme of the Internet Protocol (IP). However, since connections on higher-layers such as TCP connections are defined with the IP addresses (and ports) of the communicating nodes, the connection breaks if one of the nodes changes its IP address, e.g., due to movement.
Mobile IPv6 (Johnson et al., 2004) is an IP-based mobility protocol that enables MNs to move between subnets in a manner transparent for higher layers and applications, i.e. without breaking higher-layer connections. Therefore, a MN has two IP addresses configured: a Care-of-Address (CoA) and a Home Address (HoA). The MN's higher layers use the HoA for communication with the communication partner (destination terminal), from now on called Correspondent Node (CN). This address does not change and serves the purpose of identification of the MN. Topologically, it belongs to the Home Network (HN) of the MN. In contrast, the CoA changes on every movement resulting in a subnet change and is used as the locator for the routing infrastructure. Topologically, it belongs to the network the MN is currently visiting. One out of a set of Home Agents (HA) located on the home link maintains a mapping of the MN's CoA to MN's HoA and redirects incoming traffic for the MN to its current location. Reasons for having a set of HAs instead of a single HA are redundancy and load balancing.
Mobile IPv6 (MIPv6) currently defines two modes of operation: bi-directional tunnelling and route optimization. If bi-directional tunnelling is used, data packets sent by the CN and addressed to the HoA of the MN are intercepted by the HA in the HN and tunnelled to CoA of the MN. Data packets sent by the MN are reverse tunnelled to the HA, which decapsulates the packets and sends them to the CN. For this operation, the HA must be informed about the CoA of the MN. Therefore, the MN sends a registration message (in the following called Binding Update message, BU) to the HA. These messages are sent over an IPsec security association and thus are authenticated and integrity protected. In order for the MN to have IPsec association with the HA, the MN needs to perform bootstrapping a-priori. Bootstrapping is the process of obtaining at least the following information: a home address, a home agent address, and a security association with home agent. This information is needed before the MN registers a CoA with the home agent.
Mobile IP is categorized as host-based (or client-based) mobility management, since the mobility-related signalling is between the host (or client) and the HA. Hence, it is sometimes called Client Mobile IP (CMIP).
Another approach targets the IP mobility management in a limited geographical region, it is managed by the network and therefore is transparent to the MN. This approach is referred as network-based localized IP mobility. One main characteristic of network-based mobility is that the access network entities are appropriately configured to detect the MN movement and to exchange information about the current location of the MN, so that the MN does not need to be involved in the mobility process. Therefore the mobility-related signalling over the wireless interface is avoided. Other advantages of the network-based mobility management are less packet overhead over the air, since no MIPv6 encapsulation is needed, and mobility support for simple IP nodes (i.e., non-MIP-capable nodes).
The Internet Engineering Task Force (IETF) organisation is working on such approach for localized mobility management based on the Mobile IP protocol. Since a network entity is acting as a proxy on behalf of the MN, the protocol is called Proxy Mobile IPv6 (PMIPv6). There is a variant for IPv6 called PMIPv6 (Gundavelli et al., 2007) and a variant for IPv4 called PMIPv4 Leung et al., 2007 (K. Leung, G. Dommety, P. Yegani, K. Chowdhury, Mobility Management using Proxy Mobile IPv4, draft-leung-mip4-proxy-mode-02.txt, January 2007).
This invention assumes PMIPv6 as protocol for network-based mobility management, but the invention is not limited to PMIPv6. It may also be applicable to other network-based mobility management protocols such as PMIPv4.
PMIPv6 introduces a new logical entity called Mobile Access Gateway (MAG), which is co-located with the access router (AR) and which sends BU messages on behalf of a MN. These BU messages are marked with a flag, so that they can be identified as Proxy BU (PBU) messages. Furthermore, PBU messages contain a MN identifier (normally a Network Access Identifier, NAI, is used for this purpose) option, a home prefix option, and a timestamp (or alternatively sequence number) option. The NAI option contains the NAI [RFC4282], which has the form of “username@realm” and which is used to identify a MN.
The home prefix option contains the HoA or home prefix of the MN. In the so-called per-MN-prefix addressing model, every MN has a unique home prefix and the MN's global IP address(es) is configured based on this prefix. In cases where the MN has multiple interfaces, it is up to the network operator policy to decide whether to assign the same or different prefixes to the different MN's interfaces.
The timestamp option contains the time the PBU has been sent by the MAG and is used by the Localized Mobility Anchor (LMA) to identify the freshness of the PBU messages. If the PBU doesn't contain the timestamp option, the LMA must fall back to the sequence number scheme, as specified in the MIPv6 (Johnson et al., 2004) protocol sections 5.2.6. and 9.5. The sequence number scheme may be used when there is context transfer mechanism between the previous and new MAGs, so that the current sequence number can be communicated to the new MAG during handover procedure. For the timestamp option there is no requirement for context transfer between the MAGs during handover.
When a MN attaches to a new MAG, it authenticates with the network using the EAP framework [RFC3748] and an EAP method such as EAP-AKA [RFC4187]. The MAG typically acts as pass-through authenticator and forwards the EAP packets to the AAA server/infrastructure related to the MN. The MN may use a NAI as identifier. If the network authentication is successful, the MAG obtains the MN's profile from the AAA server.
The MAG may retrieve the Home Network Prefix (HNP) in several ways. One default way described in the specification (Gundavelli et al. 2007) is the assignment of the HNP by the LMA. In this case the MAG sends a PBU to the LMA requesting a prefix for the MN, as the HNP option in the PBU is left empty. The LMA sends a Proxy Binding Acknowledgement (PBA) back to the MAG containing the HNP.
An alternative method is the assignment of HNP by the AAA server during the authentication process. After a HNP is assigned and known by the MAG, the MAG sends unicast Router Advertisement (RA) to the MN including that prefix. The MN uses the HNP to configure a global unicast IP address. This kind of host IP configuration is known as stateless autoconfiguration.
An example of a signalling flow for PMIPv6 during initial attachment procedure in case of stateless autoconfiguration is shown in FIG. 1. The figure additionally depicts the standard Duplicate Address Detection (DAD) procedure performed by the MN whenever it configures a new IP address. The DAD procedure is performed in order to detect that the IP address is unique on the given IP link.
FIG. 2 shows the signalling flow in case of handover between MAGs within the same PMIP domain. When the MN moves to the area of AR/MAG2, it starts the authentication procedure as described in FIG. 1. After the MAG2 receives the EAP key transport message, it can start the registration process with HA sending PBU [NAI, timestamp]. MAG2 sends a PBU to the LMA in order to register the MN and to retrieve the HNP. The LMA announces the HNP in the PBA to the MAG. The MN starts checking if the current IP configuration is still valid, i.e. MN sends a RS message. AR/MAG2 responds with unicast RA containing the HNP obtained by the LMA. Since the MN receives the same prefix, it concludes that no IP link change has happened and the MN retains its IP configuration that has been configured before the handover. Now the MN has IP connectivity and can send/receive data packets.
The functionality of a HA as defined in RFC3775 is re-used to a large extent, but some changes are necessary to support PMIPv6. Henceforth, a HA as defined in RFC3775 is called just a HA and a home agent as defined in Gundavelli et al., 2007 is called Localized Mobility Anchor (LMA). A scenario is assumed in this invention where the PMIP-HA and a CMIP-HA are co-located (herinforth the CMIP/PMIP-HA is simply called HA/LMA).
Route Optimisation in MIPv6
The MIPv6 protocol comes with a Route Optimization (also abbreviated as RO) scheme that enables a direct MN-CN conversation, i.e. bypassing the Home Agent. Route Optimization requires the mobile node to register its current binding of home address to care-of-address (HoA→CoA) at the correspondent node. When this binding is known by the CN, the CN establishes a binding cache entry (similar to the HA having a binding cache entry for the MN). Packets from the CN can be routed directly to the CoA of the MN. When sending a packet to any IPv6 destination, the CN checks its cached bindings for an entry for the packet's destination address. If a cached binding for this destination address is found, the CN uses a new type of IPv6 routing header to route the packet to the MN by way of the CoA indicated in this binding.
The MIPv6 specification (Johnson et al., 2004) defines the Return Routability (also abbreviated as RR) procedure that authorizes the BU sent by the MN by the use of a cryptographic token exchange (keygen tokens). Such procedure is needed since the CN shall accept binding updates only from MNs that have previously proven the reachability for their home address and care-of-address. The binding update by the MN is signed by binding management key (Kbm) that is generated based on the keygen tokens obtained from CN separately for the home address and care-of-address. The RR procedure allows through the exchange of messages between MN and CN to verify each other without pre-arranged security association.
FIG. 3 depicts the signalling flow performed for RO. MN sends two messages to CN over different routes. One message—Home Test Init (HoTi) message—is sent to HA over the MIP IP-in-IP tunnel and afterwards HA forwards the message to CN. The other message—Care-of Test Init (CoTi)—is sent directly to CN. Both messages HoTi and CoTi contain cookies that are returned by the CN back to the MN. After receiving the HoTi and CoTi messages, the CN sends two messages back to the MN again over different routes. Home Test (HoT) message is sent to the MN's HoA, i.e. to the HA, and the HA forwards the message to the MN over the MIPv6 tunnel. Care-of Test (CoT) is sent directly to the MN.
Both messages HoT and CoT contain “home keygen token” and “care-of keygen token” respectively. They are based on CN's currently active secret key, nonces, and home or care-of address (respectively). After the HoT and CoT messages arrive at the MN, the MN uses the keygen tokens and generates Binding Update (BU) message and sends it to the CN. After receiving the message, the CN can update its binding cache with the binding of MN's HoA and CoA. The detailed RR and RO procedures are described in sections 5.2, 6.1, 9.4 and 9.5 in Johnson et al., 2004. RFC4866 (J. Arkko, C. Vogt, W. Haddad, “Enhanced Route Optimization for Mobile IPv6”, RFC 4866, May 2007) specifies an Enhanced Route Optimization mechanism aiming to provide lower handover delays, increased security, and reduced signalling overhead. This document assumes the deployment of cryptographically generated home addresses as specified in RFC3972 that increases the security. In order to reduce the handover delay, the document specifies a mechanism where the MN after a handover may send an “early binding update” (early BU) signed solely by the HoT keygen token obtained by the CN before the handover. The early BU contains a CoTi message as well. At reception of the early BU the CN verifies the used sign and if the result is positive, it establishes a temporary BCE for the MN. The CN further sends binding update acknowledgement (BA) appending the reply to the CoTi message, i.e. including the CoT keygen token. After the MN receives the BA, it generates and sends a “complete BU” to the CN. At reception of the complete BA, the CN updates the MN's BCE. More details about the enhanced Route Optimization can be found in Arkko et al., 2007.
Route Optimization in PMIPv6
Route Optimization in PMIPv6 is not specified at this moment. However, there are two main groups of approaches describing how that could be achieved.
Please note the route-optimized path is sometimes called route-optimized tunnel because the entities performing RO include additional IP header options that help the processing of the packets in end nodes, but does not influence the routing in the Internet.
RR-Based PMIP RO Approach
The Internet Draft (B. Sarikaya, A. Qin, A. Huang, W. Wu, “PMIPv6 Route Optimization Protocol”, draft-qin-netlmm-pmipro-00.txt, February 2008) describes the applicability of Enhanced Route Optimization for Mobile IPv6 specified in RFC4866 for PMIPv6. The MAG, to which the MN is attached, performs Return Routability procedure with the CN (or CN's MAG) on behalf of the MN to obtain the “home keygen token” and “care-of keygen token”. The MAG's IP address is used as CoA. Optionally the MAG may uses cryptographically generated home addresses so that no more home test is needed after the initial home test. Handover home keygen token is used during handover in order to eliminate home test for the next MAG. Thus, the MN's MAG establishes a BCE in the CN (or CN's MAG). In such case, the packets from CN are sent to the MN's MAG address (that has the role of MN's CoA). If the CN is mobile, then it is advantageous if the CN (or CN's MAG) establishes a BCE in the MN's MAG as well. This could be achieved by the RR procedure. This is depicted in FIG. 4. The solid line shows the route optimized path between MAG1 and MAG2, whereas the dotted line depicts the route before the route optimization via HA/LMA1 and HA/LMA2. The callouts at MAG1 and MAG2 show the BCEs that are established those entities after the exchange of proxy binding updates.
Further, the method proposed in Sarikaya et al., 2008, suggests a context transfer between previous and new MAGs, when the MN is in process of handover, in order to let the new MAG know the home keygen token from the CN to be able to send early BU. The result is a route-optimized path between MN's MAG and CN's MAG. The whole procedure is transparent to the end nodes.
In summary, Sarikaya et al., 2008, proposes a PMIP RO approach that is based on the RR procedure. The advantage is that the MAGs may not have a trust relationship and can establish it dynamically via the RR procedure.
LMA-MAG Exchange-Based Approach (LMA-Based PMIP RO)
There is another general approach for PMIP RO that is based on the RO-related message exchange between the involved LMAs and MAGs. This general approach with different flavours is described in M. Liebsch et al., 2007 (M. Liebsch, L. Le, J. Abeille, “Route Optimization for Proxy Mobile Ipv6”, draft-abeille-nettlmm-proxymip6ro-01.txt, November 2007); R. Koodli et al., 2008 (R. Koodli, K. Chowdhury, “Local Forwarding in Proxy Mobile IPv6”, draft-koodli-netlmm-local-forwarding-00.txt, July 2008); and A. Dutta et al., 2008 (A. Dutta et al., “Proxy MIP Extension for Inter-MAG Route Optimization”, draft-dutta-netImm-pmipro-01.txt, July 2008). The common concept of all these documents is that one LMA (if both the communicating MNs are attached to the same LMA) or more LMAs (if the communicating MNs are attached to different LMAs) take the decision for PMIP RO and instruct the MAGs to forward the data packets directly between each other. It is assumed that the MAGs that set up the RO tunnel are a part of the same network operator or at least they trust each other, so that they can establish a security tunnel among each other to forward data packets.
One example of how this approach works can be given based on the scenario from FIG. 4. There should be the pre-assumption that LMA1 and LMA2 can somehow discover and agree that PMIP RO between MAG1 and MAG2 is needed and shall be performed. Than the LMAs exchange information about the MNs and corresponding MAGs, e.g. LMA2 may inform LMA1 that a PMIP RO between MN1 and MN2 is desired and that MN2 is attached to MAG2.
Consecutively, LMA1 generates a route update message to MAG1 to trigger MAG1 to start the forwarding over a tunnel to MAG2 for packets destined to MN2. Similarly, LMA2 sends a route update message to MAG2 to trigger MAG2 to start the forwarding a tunnel to MAG1 for packets destined to MN1.
After MAG1 and MAG2 process the route update messages they start to tunnel packets between each other for MN1-MN2 traffic.
A detailed description of such inter-LMA PMIP RO can be found in section 4.2. in Dutta et al., 2008. The approach described in this paragraph can be also called “LMA-based PMIP RO”
Both approaches—the RR-based described in B. Sarikaya et al., 2008 and the LMA-MAG exchange-based described in Liebsch et al., 2008, Koodli et al., 2008 and Dutta et al., 2008—do not consider the case where a MN located in the PMIP domain changes from network-based mobility to host-based mobility scheme or vice versa.